System and method for monitoring a validator

ABSTRACT

A system for monitoring a validator that assesses a token includes an input device for receiving messages from a machine including a validator. The messages contain data indicative of validator events such as an assessment of a token resulting in acceptance of the token and an assessment of a token resulting in rejection of the token. The system further includes a processor for deriving timing information for the validator events and for comparing the data and timing information with predetermined criteria. Personnel alerts are raised when predetermined criteria are satisfied, and maintenance of validators may be scheduled in dependence upon criteria related to assessments of tokens resulting in rejection.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.12/876,159, which was filed on 5 Sep. 2010 (the “'159 Application”). The'159 Application is a continuation of U.S. Pat. No. 7,789,294, which wasfiled on 21 Feb. 2006 (the “'294 Patent”). The '294 Patent is a nationalpriority application from AU2005900774, which was filed on 18 Feb. 2005.The entire disclosures of the '159 Application and the '294 Patent areincorporated by reference into this application.

TECHNICAL FIELD

The inventive subject matter described herein relates to a system formonitoring a validator for assessing a token and methods for monitoringa network of machines including such a validator.

At least one embodiment of the inventive subject matter has beendeveloped for use with electronic gaming machines (EGMs) and it will bedescribed hereinafter primarily with reference to this application. Itwill be appreciated, however, that the inventive subject matter is notlimited to this particular field of use. In particular, the inventivesubject matter also finds application in the fields of vending machinesand systems for controlling access to a location, a resource, or anaccount.

BACKGROUND

Any discussion of the prior art throughout the specification should inno way be considered as an admission that such prior art is widely knownor forms part of common general knowledge in the field.

EGMs which allow a user to play a game upon purchase of credit areknown. Such EGMs generally include a validator for assessing token ofsome description, which is presented or inserted by a user to effectpayment for credit. The token may be a banknote or a coin inserted intothe machine, for example. In such cases, the inserted currency must beassessed to ensure that it is not counterfeit or foreign currency. Inother cases, the token may be a card having a magnetic strip or a chip,or it may be a radio frequency (RFID) tag identifying a particular useror a user account. In such cases, the token must be assessed to ensurethat it is of a type that may be used to purchase credit.

Various devices exist to perform this assessment: coin acceptors assesscoins; bill validators assess banknotes; and card and tag readers readcards and RFID tags. Except where a more limited construction is clearlyintended, the term “validator” in this document includes any device forassessing a token used to obtain credit for, or access to functionalityof, a machine, or access to a location, a resource, or an account.

It is known for validators to store status information indicative of,for example, the number of assessments performed and the number oftokens accepted/rejected. This information is accessible by maintenanceor other personnel for determining whether maintenance of the validatoris necessary.

BRIEF DESCRIPTION

It is an object of the present invention to overcome or ameliorate atleast one of the disadvantages of the prior art, or to provide a usefulalternative.

According to a first aspect of the invention there is provided a systemfor monitoring a validator that assesses a token the system including:

an input device for receiving messages from a machine including avalidator, the messages containing data indicative of validator events;

a processor for deriving timing information for the validator events andfor comparing the data and timing information with predeterminedcriteria.

Preferably, the processor derives the timing information by extractingtimestamp information from the messages.

Preferably, the processor derives the timing information with referenceto the time of receipt of the messages by the input device.

In the preferred embodiment, the input device is adapted to receivemessages indicative of the following validator events:

an assessment of a token resulting in acceptance; and

an assessment of a token resulting in rejection.

However, the input device may also be adapted to receive messagesindicative of the following additional validator events:

removal of a token storage device for storing accepted tokens; and

acceptance and storage of a token resulting in a token storage devicebeing full.

Preferably, the processor is adapted to determine occasions when anassessment of a token resulting in rejection is followed by a period ofgreater than a predetermine duration without an assessment resulting inrejection or an assessment resulting in acceptance. Such occasions arehereinafter referred to as “walk-away events”.

In such cases, the predetermined criteria preferably include thecriterion that a walk-away event has occurred.

Preferably, the criteria include the criterion that a number ofassessments resulting in rejection exceeds a predetermined thresholdnumber.

For example, the number of assessments resulting in rejection may be thenumber of assessments resulting in rejection occurring within apredetermined window. The predetermined window is preferably apredetermined number of consecutive assessments. Alternatively, thepredetermined window may be the most recent m assessments, where m is apredetermined number or a predetermined time interval.

Preferably, for each assessment resulting in acceptance, the messageincludes data identifying a type of the token.

The criteria preferably includes the criterion that the proportion ofassessments resulting in acceptance of a particular type of token fallsbelow a second predetermined threshold.

For each assessment resulting in rejection, the message preferablyincludes data indicative of a reason for rejection.

In a preferred embodiment, the processor outputs a signal when at leastone of the criteria is satisfied; and an output device is provided whichis responsive to the signal for outputting an alert signal.

The alert signal is preferably output to an alert device adapted toattract the attention of an operator. The alert device may include, forexample, a pager device, a mobile telephone, a public address system ora computer.

Preferably, the criteria includes the criterion that a “token storefull” event message or a “token store removal” is received.

The system preferably includes a collating device for collating receiveddata, for example in the form of a SQL database.

Preferably, the input device is adapted to receive messages from aplurality of validators included in respective machines and each messageidentifies the machine from which it is received.

The input device is preferably adapted to poll the plurality of machinesperiodically for messages.

Preferably, the system includes memory adapted to store a map indicatingthe location of each machine. The alert signal preferably then includesdata identifying the location of the machine from which the message wasreceived that gave rise to the alert signal.

Preferably, the system further includes a user input device for enablinga user to interact with the system.

In addition, the system is preferably adapted to poll the or eachmachine for meter information indicative of accumulated history ofevents.

A second aspect of the invention provides a method of monitoring theperformance of a validator for assessing a token, the method includingthe steps of:

receiving messages containing data indicative of validator events;

deriving timing information for the validator events; and

comparing the data and timing information with predetermined criteria.

The step of deriving the timing information preferably includesextracting timestamp information from the messages.

Preferably, the step of deriving the timing information is performedwith reference to the time of receipt of the messages by the inputdevice.

The messages are preferably indicative of the following validatorevents:

an assessment of a token resulting in acceptance; and

an assessment of a token resulting in rejection.

Preferably, the method further includes the step of determiningwalk-away events. In such cases, the predetermined criteria preferablyinclude the criterion that a walk-away event has occurred.Alternatively, the predetermined criteria may include the criterion thatgreater than a predetermined threshold number of walk-away events haveoccurred.

Preferably, the predetermined criteria include the criterion that anumber of assessments resulting in rejection exceeds a predeterminedthreshold number.

The method preferably further includes the step of outputting an alertsignal when at least one of the predetermined criteria are satisfied.For example, the alert signal may be output to an alert device forattracting the attention of an operator.

In the preferred embodiment, the method includes receiving messages froma plurality of validators included in respective machines.

A third aspect of the invention provides a machine operable by a userproviding a token, the machine including:

a token validator for assessing the token and generating an internalacceptability message indicative of whether the token is acceptable; and

an output device responsive to the internal acceptability message foroutputting an external acceptability message to an external device, theexternal acceptability message including timestamp informationindicative of the time of generation of the internal acceptabilitymessage.

The machine preferably further includes a primary processor responsiveto the internal acceptability message for implementing a primaryfunction of the machine, and the output device is disposed in acommunications path between the validator and the primary processor, theoutput device allowing messages to pass through from the validator tothe primary processor.

Preferably, the external acceptability message preferably includes dataindicative of a type of the token.

In the event of a token being rejected, the external acceptabilitymessage preferably includes data indicative of the reason for rejectionof the token.

The machine preferably further includes a token storage device and theoutput device additionally outputs messages indicative of token storagedevice events.

Preferably, the output device buffers the received internalacceptability messages and preferably outputs the buffered messages inresponse to a polling signal received from the external device.

Preferably, the output device includes a network interface device forfacilitating communication between the output device and the externaldevice.

In some embodiments, the primary function of the machine is to provide agame. In others, the primary function of the machine is to sell an item,for example a ticket.

Preferably, the token is currency, for example a coin or preferably abanknote.

A fourth aspect of the invention provides a validator monitoring devicefor inclusion in a machine operable by a user providing a token, thedevice including:

an input device for receiving from a token validator for assessing theacceptability of tokens a validator event message containing dataindicative of a validator event; and

an output device responsive to the validator event message foroutputting a further message including timestamp information indicativeof the time the validator event occurred.

The device preferably further includes a buffer device for bufferingreceived validator event messages for output to the external device.

Preferably, said output device outputs the messages to the externaldevice in response to a polling signal received from the externaldevice.

The device preferably further includes a pass-through channel forpassing the validator event messages to a further device.

A fifth aspect of the invention provides a method of monitoring anetwork including a plurality of machines having respective validatorsand a monitoring system, the method including the steps of:

at the machines, generating messages including data indicative ofvalidator events including acceptance and/or rejection of tokens; and

at the monitoring system:

receiving the messages at the monitoring system; and

comparing the data with predetermined criteria.

The method preferably further includes the step of, for each messagereceived at the system, deriving timing information for the respectivevalidator event, and wherein the predetermined criteria includes atleast one timing-related criterion.

The method preferably also includes the step of determining walk-awayevents, being occasions when an assessment of a token resulting inrejection is followed by a period of greater than a predeterminedthreshold duration without an assessment resulting in acceptance or anassessment resulting in rejection.

The method preferably includes:

collating performance data for each machine; and

manipulating numbers of walk-away events with reference to performancedata of the machines.

In a particular embodiment, the method includes:

collating performance data for each machine;

for each machine, determining a ranking as a function of at least oneof:

anticipated transactions over a predetermined time interval,

number of walk-away events occurring at the machine,

total number of walk-away events at machines in the system, and

number of machines in the system; and

prioritizing maintenance of the machines in dependence upon therankings.

Furthermore, when monitoring a network in which each machine is arepresentative of one of a number of types of machine, the method mayalso include the steps of:

collating performance data for each machine type; and

determining the ranking in dependence upon at least one of:

anticipated transactions by machine type;

number of walk-away events by machine type.

For example, the ranking for a machine of a particular type may bedetermined as a function of some or all of:

the anticipated activity at that machine;

the anticipated total activity at machines of that type;

the number of machines of that type;

the total number of machines;

the number of walk-away events at that machine; and

the total number of walk-away events at machines of that type.

The general level of activity at machines in the system may also be afactor in the determining of the ranking.

Additionally or alternatively, the method may include the step ofdetermining a respective predetermined threshold duration for eachmachine in dependence upon the respective machines' associatedperformance data or, where each machine is a representative of one of anumber of types of machine, determining a respective predeterminedthreshold duration for each machine type in dependence upon theperformance data for the respective machine types.

In one embodiment of the method, the predetermined criteria include thecriterion that, at one of the machines, greater than a predeterminedthreshold number of walk-away events have occurred.

In a further embodiment, the method includes the steps of determining arespective predetermined threshold number of walk-away events for eachmachine in dependence upon the respective machines' associatedperformance data or, where each machine is a representative of one of anumber of types of machine, determining a respective predeterminedthreshold number of walk-away events for each machine type in dependenceupon the performance data for the respective machine types.

A further aspect of the invention provides a method of modifying amachine operable by a user providing a token, including a tokenvalidator for assessing the acceptability of tokens and outputtingvalidator event messages, the token validator being in communicationwith a primary processor for implementing a primary function of themachine, the method including the step of connecting to the validator avalidator monitoring device as described above such that the validatormonitoring device receives the validator event messages.

The method preferably includes the step of connecting the validatormonitoring device to the primary processor such that validator eventmessages may pass from the validator to the primary processor via thevalidator monitoring device.

A further aspect of the invention provides a network including a systemaccording to the first aspect of the invention and at least one machineaccording to the second or third aspect.

An further aspect of the invention provides a method of monitoring anetwork according to the preceding aspect including the steps of:

generating at the at least one machine messages including dataindicative of validator events including acceptance and/or rejection oftokens;

receiving the messages at the monitoring system;

comparing the data with predetermined criteria; and

outputting an alert message when at least one of the criteria issatisfied.

The method preferably includes the step of, for message received at thesystem, deriving timing information for the respective validator event,the predetermined criteria including at least one timing relatedcriterion.

Preferably, the timing information is derived from information containedin the message.

Additionally or alternatively, the timing information may be derivedfrom the time of receipt of the message at the system.

Preferably, the alert message is sent to an alert device for attractingthe attention of an operator.

Preferably, the alert message includes data identifying the machine thatgenerated the message which gave rise to the alert message.

Preferably, the alert message further includes data identifying thecriterion that was satisfied resulting in the alert message.

A further aspect of the invention provides a method of monitoring theperformance of a network of machines each including a respectivevalidator for assessing tokens, the method including the steps of:

obtaining performance data for each machine;

obtaining performance data for each validator; and

manipulating the performance data for the machines with reference to theperformance data for the validators.

Further aspects of the invention include a computer program for causinga computer to execute a method as set out above, and such a computerprogram carried by a data carrier or a signal.

BRIEF DESCRIPTION OF THE DRAWINGS

A preferred embodiment of the invention will now be described, by way ofexample only, with reference to the accompanying drawings in which:

FIG. 1 is a schematic overview of a network including a system formonitoring validators that assess tokens and a plurality of machinesoperable by respective users by providing tokens;

FIG. 2 is a more detailed schematic representation of the system formonitoring validators shown in FIG. 1;

FIG. 3 is a more detailed schematic representation of a first embodimentof a machine operable by a user providing a token shown in FIG. 1;

FIG. 4 is a more detailed schematic representation of a secondembodiment of a machine operable by a user providing a token;

FIG. 5 is a more detailed schematic representation of a third embodimentof a machine operable by a user providing a token;

FIG. 6 is a more detailed schematic representation of a fourthembodiment of a machine operable by a user providing a token;

FIG. 7 is a detail of a first graphical report that may be produced bythe system shown in FIG. 1;

FIG. 8 is a second graphical report that may be produced by the systemshown in FIG. 1; and

FIG. 9 is a schematic representation of a device for inclusion in amachine operable by a user provided with a token.

DETAILED DESCRPTION

FIG. 1 shows a network including a system in the form of a host computer1 for monitoring validators that assess tokens, and a plurality ofelectronic gaming machines 2 operable by respective users providingtokens. Except where a more limited construction is clearly intended,the term “token” in this document includes any device or signal orrepresentation of data that would be used to obtain credit for, or gainaccess to functionality of, a machine, or access a location, a resource,or an account, or otherwise to gain access to a product or process. Atoken may include but is not limited to a banknote, coin or othercurrency, or a card, ticket or other device or data carrier havingrepresentations of data, for example a magnetic strip, chip or otherdata representations, including radio frequency tags (RFID),recognizable by a validator. Without the token, access could be deniedthe user for the product or process, or otherwise they could be changedin how the user interfaces with the product or process.

The host 1 and the machines 2 communicate via internal or, as shown,external communications devices 3 in a known way. For example, variousembodiments effect communication via Ethernet, wireless Ethernet,bluetooth, or telephony networks or combinations of these types ofnetwork. In a preferred embodiment, communication between the host andthe machines occurs via a 9600-baud 8N1 RS485 multi-drop network usingCRC checking.

The host 1 is shown in more detail in FIG. 2. It includes an inputdevice 4 for receiving messages 5 from a machine 2 including a validator6, the messages containing data indicative of validator events. The hostfurther includes a processor 7, having associated memory 8, for derivingtiming information for the validator events and for comparing the dataand timing information with predetermined criteria. When at least one ofthe criteria is satisfied, the processor 7 outputs a signal to an outputdevice 9. The output device 9 responds to the signal by outputting analert signal 10.

FIG. 3 shows a first example of a machine 2 operable by a user providinga token, in this example a banknote. The machine includes a validator 6for assessing the banknote and generating an internal acceptabilitymessage indicative of whether the banknote is acceptable. A primaryprocessor 11 is responsive to the internal acceptability message forimplementing a primary function of the machine. An output device 12 isresponsive to the internal acceptability message for outputting in realtime an external acceptability message 13 to an external device, forexample the host 1 shown in FIG. 2.

The host input device 4 is adapted to poll the plurality of machines 2in sequence periodically. Messages are received from each machine 2 atwhich a validator event has occurred during the preceding pollinginterval. Each message identifies the machine 2 at which it isgenerated, by including addressing information for the machine 2, thenetwork card 3, the validator 6 or the output device 12 for example.

The processor 7 derives timing information for the validator events withreference to the time of receipt of the messages by the input device 4.For example, if the polling interval is 1 second and a polling sequencebegins at 14:36:04, all messages received during that polling sequenceare considered to have been received at 14:36:04. The validator eventswhich gave rise to the messages are also considered to have occurred at14:36:04. Alternatively, if it is known that generation and processingof messages by the machines 5 takes, say, 3 seconds, then 3 seconds maybe subtracted from this time. When an accuracy of greater than 1 secondis required, a shorter polling interval is used. Where necessary whenusing short polling intervals with networks having a large number ofmachines 2, a plurality of communications paths are used to ensure thatthe polling interval may be maintained.

A further example of a machine 2′ operable by a user providing a tokenis shown in FIG. 4. This example includes a token validator 6 forassessing the token, again a banknote in this example, and outputting aninternal acceptability message indicative of whether the banknote isacceptable. A primary processor 11 is responsive to the internalacceptability message for implementing a primary function of themachine. An output device 12′ is responsive to the internalacceptability message for outputting an external acceptability message13 to an external device. In this example, which is particularly adaptedfor use in networks in which a high degree of temporal resolution isrequired, the external acceptability message 13 includes time stampinformation indicative of the time of generation of the internalacceptability message. The time stamp information is added to themessage by a time stamping device 14. In one embodiment, absolute timestamps are used indicating absolutely the time of generation of themessage. However, in alternative embodiments, relative time stamps areused, including an offset value indicating the time offset from areference point, for example, the time of the last polling of themachine 2.

When used in combination with one or more machines 2′ of this type, thehost processor 7 derives the timing information by extracting the timestamp information from received messages. In embodiments using relativetime stamps, the host computer derives the time of generation of themessages with reference both to the time stamp information and tointernal information relating to the timing of the polling of themachines.

In the embodiment shown in FIG. 4, the machine primary processor 11 alsooutputs messages relating to the game being played on the gaming machinein a manner well-known to those in the field of networking gamingmachines. In one embodiment, the primary processors 11 of the gamingmachines 2 are linked using a network separate from the network providedfor monitoring validator activity. However, in another embodiment, thesame network is used for both purposes. In one such embodiment, theprimary processors 11 use network cards separate from those provided forthe output devices 12′. In an alternative embodiment, the output devicesand the primary processors share network cards. While this feature hasbeen described with reference to the machine shown in FIG. 4, it isequally applicable to that shown in FIG. 3.

As shown in FIGS. 3 and 4, the output device 12′ is disposed in acommunications path between the validator 6 and the primary processor11. It allows messages from the validator to pass through to the primaryprocessor and also buffers the messages for output to the host 1. In analternative embodiment, for use in networks in which polling is likelyto be at least as frequent as generation of event messages, an outputdevice is used that only stores the most recently generated eventmessage for output to the host.

The output device 12′ outputs buffered or stored messages in response tothe polling signal received from the external device.

In the preceding examples of machines shown in FIGS. 3 and 4, the outputdevice is shown as being distinct from the validator 6 and the primaryprocessor 11. However in one embodiment, shown in FIG. 5, the outputdevice 12 is integral with the validator 6′. In another embodiment,shown in FIG. 6, the output device 12 is integral with the primaryprocessor 11′.

As indicated above, validator events that cause the generation ofvalidator event messages include assessments of banknotes resulting inacceptance and assessments of banknotes resulting in rejection. Themachines 2 also include respective token storage devices in the form ofnote stackers 15. Storage device events such as the removal of the notestacker 15 or the storage of insertion of a note into the stackerresulting in the stacker being full also cause the generation of avalidator event message containing information indicative of the storagedevice event.

In addition to the information identifying the machine that generatedthe message, and the time stamp information in the case of machines 2′described above with reference to FIG. 4, each validator event messageincludes:

Information indicative of the type of event: for example, assessment ofa token resulting in acceptance (acceptance message), assessment of atoken resulting in rejection (rejection message), removal of the notestacker, the note stacker becoming full.

Further information relating to the event: in the case of an acceptancemessage, the type of the token, for example, the denomination of thebanknote; in the case of a rejection message, the reason for therejection (for example, failed optical/magnetic test, note jam).

The host 1 includes a data collating device in the form of a SQLdatabase 16 for collating the data from the received validator eventmessages. Upon receiving validator event messages, the host processor 7stores the data in the database 16. In one embodiment, after processingeach received message, the processor checks whether the stored datasatisfies any of the criteria for generation of an alert message. Inother embodiments, this step is performed once at the end of eachpolling period. In yet further embodiments, the checking is performedperiodically and separately from the polling of the machines.

The host 1 also stores in the database 16 or other memory 8 informationrelating to the various criteria against which the stored data is to bechecked to determine whether an alert signal is to be generated. A firstbroad category of criterion for generation of an alert message includesthe criterion that a number of assessments resulting in rejectionexceeds a predetermined threshold. In one embodiment, assessmentsoccurring within a predetermined window of a predetermined number m ofconsecutive assessments of an inserted banknote are considered. Forexample, for each machine 2 the processor 7 checks the most recent 100assessments and an alert signal is generated if the number of rejectionsis greater than a predetermined threshold of 10, that is that acceptancehas dropped below 90%. Different thresholds, for example representingacceptance rates of 80%, 70%, 60% and so on, and windows of differentsizes, for example 50, 200, 500 or 1000 assessments, are used asappropriate, according to preference. This type of criterion may be ofassistance particularly in identifying validators whose ability toidentify correctly inserted banknotes is declining.

In another embodiment, assessments occurring within a predetermined timeinterval m are considered. In this embodiment, for each machine 2 theprocessor 7 checks assessments within a time interval, for example, thepreceding 15 minutes, and an alert signal is generated if the number ofrejections is greater than a predetermined threshold of 2. This type ofcriterion may be of assistance particularly in identifying a machine 2at which a user requires assistance, for example because they are notaware that a token that they are attempting repeatedly to insert isinvalid—such as the wrong type of card or a counterfeit banknote. It mayalso be of assistance in identifying a machine at which a user isattempting to launder counterfeit banknotes.

A second category of criterion includes the criterion that theproportion of assessments at a particular machine 2 resulting inacceptance of a particular type of token falls below another threshold.For example, if the proportion of acceptances that relate to $10 notesfalls below a threshold value, this may be indicative of a decline in aparticular validators ability to identify $10 notes correctly. In someembodiments, the threshold is determined with reference to theproportions of the various denominations being accepted at all machines.In other embodiments, the threshold is determined with reference tohistorical data, for example relating to the typical proportionsexpected at a particular time of day.

A further broad category of criterion includes the consideration ofwalk-away events. A walk-away event is defined as an occasion when anassessment of a token resulting in rejection of that token is followedby a period of greater than a predetermined threshold duration withoutan assessment resulting in rejection or an assessment resulting inacceptance. In some embodiments, a more limited definition may be used:i.e. a walk-away event is an occasion when a series of greater than apredetermined number of assessments resulting in rejection of a tokenoccurs within a predetermined time interval, and the series ofassessments resulting in rejection is followed by a period of greaterthan a predetermined threshold duration without an assessment resultingin rejection or an assessment resulting in acceptance.

Such events are of interest since, in a retail or gaming scenario, theymay be indicative of lost revenue in that an intended user of a machinehas attempted to effect a transaction, but has been prevented by thevalidator. On some such occasions, the user may use another machine,resulting in no loss of revenue, but perhaps in irritation to the user.On other such occasions, however, the result may be that the userabandons the attempted transaction altogether. In other scenarios, forexample automated ticket sales at transport stations, the walk-awayevents may result in increased demand on manned sales points. Increasingthe need for such points, and their associated cost.

The processor 7 also checks whether a message has been receivedindicating that a note stacker 15 is full or that it has been removed.Such criteria may assist staff at a venue to identify machines 2 thatrequire attention—for example, emptying of the note stacker 15—or tohave greater information to monitor the emptying of note stackers 15 bynoting the precise time a stacker is removed.

A user input device 17, for example a keyboard and/or a mouse incombination with a graphical user interface, is provided for enabling auser having a password to interact with the system, add or modify thevarious criteria and thresholds and the destinations of alert signals,and add, modify or remove details of particular machines 2. The inputdevice 17 is also used by a user to access various reports. Reportsavailable to a user include graphs for each machine 2 representingacceptance or rejection proportions against time, including proportionsover various time intervals a detail of one of which is shown in FIG. 7and lists of machines 2 which are offline. Other reports include listsof machines 2 that are performing above or below respective general ormachine-specific criteria, for example acceptance percentages, includinginformation indicative of actual performance. In a particularembodiment, these lists are limited to machines 2 at which more than apredetermined threshold number of assessments have been made, to avoidundue attention being paid to machines 2 for which the amount ofavailable data is statistically insignificant. This threshold may be setby the user. FIG. 8 shows a further report in the form of a scattergraph showing the acceptance proportions for each machine in a network.

A number of examples of methods of monitoring walk-away events will nowbe provided with reference to a gaming establishment having thirtygaming machines each having respective validators and eachinterconnected in a manner described above. General performance data forthe various machines is collated in manner known to those skilled in theart. Furthermore, performance data for the validators in the machines iscollated in a manner described above.

Over a period of one week, the walk-away events occurring are summarizedin the following table:

TABLE 1 Walk-Away Events Machine # Event Time 11 07 Feb. 2006 1:23:26 PM1 07 Feb. 2006 8:39:21 PM 19 07 Feb. 2006 9:02:08 PM 9 08 Feb. 200610:53:40 PM 17 08 Feb. 2006 11:32:50 PM 16 08 Feb. 2006 5:50:07 PM 16 08Feb. 2006 7:01:55 PM 8 08 Feb. 2006 8:12:54 PM 30 08 Feb. 2006 8:16:16PM 28 09 Feb. 2006 7:30:07 PM 24 09 Feb. 2006 9:07:20 PM 9 09 Feb. 200610:36:33 PM 17 09 Feb. 2006 10:36:50 PM 20 09 Feb. 2006 10:55:04 PM 1209 Feb. 2006 11:10:52 PM 17 10 Feb. 2006 3:00:40 PM 20 10 Feb. 20065:07:13 PM 28 10 Feb. 2006 5:57:06 PM 1 10 Feb. 2006 6:41:26 PM 30 10Feb. 2006 6:50:53 PM 26 10 Feb. 2006 9:05:00 PM 24 10 Feb. 2006 9:13:25PM 29 10 Feb. 2006 9:20:29 PM 6 10 Feb. 2006 9:22:38 PM 13 10 Feb. 200610:02:26 PM 30 11 Feb. 2006 12:12:49 AM 3 11 Feb. 2006 12:46:30 AM 30 11Feb. 2006 11:21:44 AM 9 11 Feb. 2006 11:45:15 AM 30 11 Feb. 2006 4:08:33PM 6 11 Feb. 2006 6:16:52 PM 19 12 Feb. 2006 1:01:15 AM 8 12 Feb. 20065:05:56 PM 24 12 Feb. 2006 5:07:12 PM 4 12 Feb. 2006 6:14:00 PM

In a simple embodiment, an operator is alerted when a walk-away eventoccurs, or when the number or frequency of walk-away events occurring ata particular machine reaches a predetermined threshold value. However,other embodiments provide more sophisticated methods of consideringwalk-away events.

In one such embodiment, the total number of walk-away events in aspecified time interval in a venue having a number of machines ismonitored. An example of this is shown in the following table:

TABLE 2 Walk-Awa Events b dare Date Walk-Away Events 07 Feb. 2006 3 08Feb. 2006 6 09 Feb. 2006 6 10 Feb. 2006 10 11 Feb. 2006 6 12 Feb. 2006 413 Feb. 2006 0 Total 35

Such information may be correlated with information relating to generalactivity in a venue. The tracking of walk-away events during a specifiedtime interval in this way may allow an operator to identify peaks inwalk-away activity, which may be indicative of attempted use ofcounterfeit currency, particularly where peaks in walk-away activity donot correspond with peaks in general activity.

In another embodiment, the number of walk-away events is monitored bymachine. This is illustrated in Table 3 below:

TABLE 3 Walk-Awa Events b Machine Machine Walk-Away Machine # typeEvents 1 A 2 3 B 1 4 C 1 6 D 2 8 B 2 9 E 3 11 F 1 12 G 1 13 H 1 16 I 217 J 3 19 K 2 20 K 2 24 L 3 26 M 1 28 K 2 29 N 1 30 J 5

In this way, it may be readily seen which machines are suffering thegreatest number of walk-away events. This information may be used forthe purposes of prioritizing the maintenance of the validators (e.g.replacement or repair). More sophisticated method of prioritizingmaintenance are described below.

In a first such method, regard is had to the number of transactionsexpected at a particular machine in a specified time period. Thisinformation may be derived, for example, from historical data relatingto activity at the various machines. Since it is likely that priorityshould be given to machines having large numbers of anticipatedtransactions in a given time interval (say, one hour) and large numbersof walk-away events in a time interval, multiplying these two factorsmay result in a figure by which the machines may be prioritized formaintenance. An example of this is given in Table 4, below:

TABLE 4 Machines ranked for maintenance by Walk-Away Events ×anticipated transactions per hour Anticipated Anticipated transactionsat transactions at Walk-Away machine × # Machine # machine/hour Eventswalk-away events 30 16 5 80 24 19 3 57 1 17 2 34 17 11 3 33 19 15 2 30 614 2 28 16 14 2 28 20 13 2 26 9 7 3 21 13 16 1 16 29 16 1 16 3 15 1 15 87 2 14 12 12 1 12 11 10 1 10 26 2 1 2 2 18 0 0 4 0 1 0 5 1 0 0 7 8 0 010 11 0 0 14 18 0 0 15 11 0 0 18 6 0 0 21 0 0 0 22 7 0 0 23 5 0 0 25 8 00 27 5 0 0 28 0 2 0

In some contexts, for example in gaming venues, the machines connectedto a system may each be examples of a particular machine type. In agaming venue, each machine provides a particular game, and the variousgames may have varying degrees of popularity. Table 5 below shows themachines ranked according to the product of the number of walk-awayevents at the respective machines and the anticipated total number oftransaction at the type of machine. The anticipated total number oftransactions at a particular machine type may again be derived fromhistorical activity data.

TABLE 5 Machines ranked for maintenance by Walk-Away Events ×anticipated transactions per hour at machine type AnticipatedAnticipated transactions transactions at Machine at machine Walk Awaymachine type × # Machine # type type/hour Events walk-away events 30 J27 5 135 17 J 27 3 81 1 A 35 2 70 6 D 30 2 60 24 L 19 3 57 19 K 28 2 5620 K 28 2 56 28 K 28 2 56 8 B 23 2 46 13 H 34 1 34 12 G 29 1 29 16 I 142 28 3 B 23 1 23 9 E 7 3 21 29 N 21 1 21 11 F 18 1 18 4 C 15 1 15 26 M 21 2 2 A 35 0 0 5 B 23 0 0 7 C 15 0 0 10 D 30 0 0 14 H 34 0 0 15 G 29 0 018 G 29 0 0 21 K 28 0 0 22 C 15 0 0 23 D 30 0 0 25 F 18 0 0 27 N 21 0 0

In a final example, it may be that the various machine types havevarying popularity and that particular machines within a machine typealso have varying degrees of popularity. Table 6 below therefore showsthe machines ranked by the product of the anticipated number oftransactions at a particular machine (to take account of the popularityof that specific machine), the total number of transactions at themachine type (to take account of the relative popularities of themachine types), and the number of walk-away event occurring at themachines.

TABLE 6 Machines ranked for maintenance by Walk-Away Events ×anticipated transactions per hour at machine type × anticipatedtransactions per hour at machine Anticipated Anticipated Anticipatedtransactions at transactions transactions Walk machine × anticipatedMachine Machine at machine/ at machine Away transactions at machine #type hour type/hour Events type × # walk-away events 30 J 16 27 5 2160 1A 17 35 2 1190 24 L 19 19 3 1083 17 J 11 27 3 891 6 D 14 30 2 840 19 K15 28 2 840 20 K 13 28 2 728 13 H 16 34 1 544 16 I 14 14 2 392 12 G 1229 1 348 3 B 15 23 1 345 29 N 16 21 1 336 8 B 7 23 2 322 11 F 10 18 1180 9 E 7 7 3 147 26 M 2 2 1 4 2 A 18 35 0 0 4 C 0 15 1 0 5 B 1 23 0 0 7C 8 15 0 0 10 D 11 30 0 0 14 H 18 34 0 0 15 G 11 29 0 0 18 G 6 29 0 0 21K 0 28 0 0 22 C 7 15 0 0 23 D 5 30 0 0 25 F 8 18 0 0 27 N 5 21 0 0 28 K0 28 2 0

The above examples are each examples of a more general strategy ofranking the gaming machines by a factor determined as a function ofvarious parameters. The ranking factor for a particular machine, R_(i),may be generalized as:R _(i)ƒ(A _(i) A(T _(i)),n(T _(i)),n, W_(i) , W(T _(i)))where A_(i) is the anticipated activity (e.g. number of transactions) ata particular machine in a predetermined time interval, A(T_(i)) is theanticipated total activity at machines of the same type as theparticular machine during the same predetermined time interval, n(T_(i))is the total number of machines of the same type as the particularmachine, n is the total number of machines in the network, W_(i) is thenumber of walk-away events at the particular machine in a specified timeinterval, and W(T_(i)) is the total number of walk-away events atmachines of the same type as the particular machine in the same timeinterval.

In the above examples, the coefficients or exponents of some of theparameters are zero while others are 1. Other strategies are possible inwhich the coefficients or exponents take other values. For example, itmay be determined that a machine should be considered a lower priorityif it is of a type of which there are a number of examples in thesystem: n(T_(i)) may therefore have a negative exponent. However to takeaccount of user preferences for a particular machine regardless of theavailability of others of the same type, the exponent may have anabsolute value of less than one: e.g. −0.5.

The strategy appropriate for a particular network may also depend uponvarious other factors such as overall activity in a system. For example,in a gaming venue where activity is approaching the total capacity ofthe venue, the existence of more than one machine of a type will be ofless relevance, since an intended user of a particular machine may findno other examples of that machine type available to him. Conversely,where overall activity is low, a user may easily find another example ofa particular machine type.

Scheduling of maintenance may be automated to some extent by use of thesystem described above, and messages may be sent to a pager or othercommunications device as described above, specifying the next machine onwhich maintenance is to be performed.

As indicated above, walk-away events are occasions on which anassessment of a token resulting in rejection of that token is followedby a period of greater than a predetermined threshold duration withoutan assessment resulting in rejection or an assessment resulting inacceptance. In one embodiment, in which the definition of a walk-awayevent is intended as closely as possible to reflect the actualoccurrences of a user attempting to insert a token into validator andabandoning the attempt after a rejection, the predetermined thresholdduration is fixed, and is identical for all machines. For example, twominutes may be appropriate.

However, in addition to or as an alternative to the methods describedabove of considering walk-away events and managing the varyingpopularity of machines and machine types, the predetermined thresholdduration may differ for different machines or machine types.Furthermore, the predetermined threshold durations may change dependingupon general levels of activity or anticipated levels of activity.

Different levels of security may be used in a known way for example toallow some users to view database reports while preventing modificationof criteria, thresholds and so on.

The database 16 also includes information identifying othercharacteristics of the machines 2, for example the game being providedby the machines 2, current status—online or offline, identificationnumbers of the machines 2, and the location of the various machines 2.In one embodiment, this location information is purely textual. However,in other embodiments, images such as floor plans and image/textcombinations are used.

When one of the criteria for generation of an alert signal is satisfied,the processor 7 sends a signal to the output device 9, which responds bysending the alert signal to an alert device 8 adapted to attract theattention of an operator. Various types of alert device 18 are used invarious embodiments, including pager devices, mobile telephones usingSMS or automated voice calls, public address systems, computer devicesusing email or network alerts, and so on.

The alert signal identifies the machine 2 giving rise to the alertsignal, including textual and/or graphical information about thelocation of the machine 2. The signal also includes informationindicative of the reason for the alert signal. In a particularembodiment, alert signals generated in response to different types ofcriteria are sent to different alert devices 18 to attract the attentionof different personnel. For example with reference to FIG. 7, a spike inthe number of rejections occurring over a short time might cause asignal to be sent to a device to alert customer service and/or securitypersonnel; the proportion of rejections within a preceding number ofinsertions of banknotes rising above a threshold or a note jam mightcause a signal to be sent to a device 18 to alert maintenance personnel.For testing purposes, an alert signal may be sent simply when a note isaccepted or rejected, for example after maintenance of a validator 6. Analert signal may also be sent when a note of a particular denominationis accepted, for example a high value note, or when tampering with thevalidator is detected.

To provide further data, the host 1 may upon request of a user and/orperiodically poll the various machines 2 for meter informationindicative of the total number of acceptances and rejections of variousdenominations, for example, since the last poll or some other referencepoint, as an indication of the history of events. This information maybe retrieved from memory in the output devices or from the validatorsthemselves. This may be of assistance in rapidly recommencing monitoringin the event that the host computer is offline for a period.

Turning to FIG. 9, a particular embodiment provides separately avalidator monitoring device 12′, equivalent to the output device 12described above, for inclusion in a machine operable by a user providedwith a token. The device includes an input device 19 for receiving froma token validator for assessing the acceptability of tokens a validatorevent message 20 containing data indicative of a validator event. Anoutput device 21 is responsive to the validator event message foroutputting a further message 22 in real time to an external device suchas the host 1 for example via a network as described above withreference to FIG. 1. Such a monitoring device 12′ may be retrofitted toan existing machine to allow its validator 6 to be monitored asdescribed above. In a particular embodiment, the further message 22includes time stamp information indicative of the time the validatorevent occurred. In one embodiment, this time stamp information isreceived in the validator event message 20 and simply passed through thedevice 12′. In another embodiment, the device 12′ inserts the time stampinformation into the message. In embodiments in which the device itselfadds the time stamp information, the outputting of the further messageneed not be in real time.

The device 12′ further includes a buffer device 23 for bufferingreceived validator event messages 20 for output to the external device.The output device 21 outputs the messages 22 to the external device inresponse to a polling signal received from the external device, asdescribed above.

In a particular embodiment, the device 12′ is intended to be insertedinto the machine in the communications path between the validator 6 andthe primary processor 11 of the machine. In such cases, the device 12′further includes a pass-through channel 24 for passing the validatorevent messages 20 to the machine primary processor 11.

In addition to monitoring individual validators, the invention alsofinds application in the monitoring of a network of machines. Forexample, it is known to monitor the turnover of various gaming machinesto identify favoured locations on a gaming floor or to identify populargames. Manipulation of the machine performance data with reference tovalidator performance data may assist in formulating accurateconclusions from the machine performance data. For example, a machinewhich has low turnover but which also has a low acceptance rate may beomitted from consideration of the popularity of the game being providedby that machine. Additionally or alternatively, gaming floor locationsat which acceptance levels are consistently low may be identified asrequiring additional security measures.

Although the invention has been described primarily with reference toits application in networks of electronic gaming machines, it will beclear to those skilled in the art that it also finds application manyother forms. In particular, the invention finds application inconnection with other machines, for example vending machines forconfectionery or tickets, and ticket or card-operated gates and so on.Furthermore, features of the various described examples may be providedin any combination.

Additionally, the various functionalities have been described as beingperformed by distinct devices, such as integrated circuits. However, inpreferred embodiments, all or any combination of functionalities mayinstead be performed by multi-purpose integrated circuits or implementedin software executed by a processor. Particularly in such cases, theinvention may additionally be embodied in a computer program or in acomputer program in a data signal or stored on a data carrier.

The invention claimed is:
 1. A system comprising: an input deviceconfigured to receive messages from plural machines having validatorsthat assess payment tokens, the messages indicative of at least one ofacceptance or rejection of the payment tokens; and a processorconfigured to identify a walk-away event at a first machine of themachines when a first validator at the first machine rejects a firstpayment token and at least a threshold time period expires followingthis rejection without the first validator accepting or rejecting asecond payment token, the processor also configured to request servicingof at least one of the first validator or the first machine based on thewalk-away event, wherein the processor is configured to requestservicing of one or more of the validators or the machines according toa priority that is based on walk-away events identified at the machines.2. The system of claim 1, wherein the processor is configured toidentify the walk-away event when a number of assessments of the paymenttokens at the first machine resulting in rejection of the payment tokensexceed a designated threshold.
 3. The system of claim 1, wherein themessages received from the machines identify which of the machinestransmitted the messages.
 4. The system of claim 1, wherein theprocessor is configured to periodically poll the machines to receive themessages.
 5. The system of claim 4, wherein the processor is configuredto receive the messages from only those of the machines having thevalidators that assessed one or more of the payment tokens since aprevious polling of the machines.
 6. The system of claim 4, wherein theprocessor is configured to determine times of receipt for the messagestransmitted from the machines during a first polling cycle, theprocessor configured to make the times of receipt for the messagesreceived during the first polling cycle as equivalent to a time at whichthe first polling cycle begins regardless of when the messages areactually received by the processor.
 7. The system of claim 1, whereinthe machines are gaming machines that receive the payment tokens inorder to allow players to play games at the machines.
 8. A systemcomprising: an input device configured to receive messages from pluralmachines having validators that assess payment tokens, the messagesindicative of at least one of acceptance or rejection of the paymenttokens; and a processor configured to identify a walk-away event at afirst machine of the machines when a first validator at the firstmachine rejects a first payment token and at least a threshold timeperiod expires following this rejection without the first validatoraccepting or rejecting a second payment token, the processor alsoconfigured to request servicing of at least one of the first validatoror the first machine based on the walk-away event, wherein the processoris configured to periodically poll the machines to receive the messages.9. The system of claim 8, wherein the processor is configured to requestservicing of one or more of the validators or the machines according toa priority that is based on walk-away events identified at the machines.10. The system of claim 8, wherein the processor is configured toidentify the walk-away event when a number of assessments of the paymenttokens at the first machine resulting in rejection of the payment tokensexceed a designated threshold.
 11. The system of claim 8, wherein themessages received from the machines identify which of the machinestransmitted the messages.
 12. The system of claim 8, wherein theprocessor is configured to receive the messages from only those of themachines having the validators that assessed one or more of the paymenttokens since a previous polling of the machines.
 13. The system of claim8, wherein the processor is configured to determine times of receipt forthe messages transmitted from the machines during a first polling cycle,the processor configured to make the times of receipt for the messagesreceived during the first polling cycle as equivalent to a time at whichthe first polling cycle begins regardless of when the messages areactually received by the processor.
 14. The system of claim 8, whereinthe machines are gaming machines that receive the payment tokens inorder to allow players to play games at the machines.